When data is sent over most modern communication networks, the data is packaged in a layered structure referred to as a “protocol suite” or “protocol stack”. The data sent by the sender can be viewed as being wrapped in a multi-layer package in which each layer facilitates the transmission of the data through various hardware and software stages that separate the sender of the data from the final recipient.
There are a number of applications in which a third party, i.e., someone other than the sender and receiver, needs to decode the packets en route to obtain information that identifies the sender, receiver, and/or data being sent. A program for providing this function must be able to decode the packets to the level at which the desired information can be extracted. In some cases, this information needs to be extracted in real time, which further complicates the decoding software.
At each layer in this multi-layer package, there is generally information that identifies the protocol that is used for that layer and the layout of that layer, although many protocols exist in which there is no information in the layer at all about the layout, length or location and type of the next layer. The protocol of the outer layer is usually set by the communication link in question. However, the inner layers can vary considerably. There is no “index” of the packet layers at a known location in the packet. Hence, to decode the packets, the decoding program must “peal back” each layer in turn. This process involves decoding the header record for a layer, extracting data that specifies how that layer is configured, and, based on the extracted data, either reading the data of interest and/or jumping to a new location at which the next layer of interest has a header.
The number of different packet formats on any given communication link can be quite large. Hence, custom programs are needed for each type of communication link and application. At present, the task of writing a program to decode traffic is further complicated by the need to write the code in terms of the absolute location of the fields of interest within the data packets. For the purposes of this discussion, the absolute location of a field in a data packet is the offset of that field from the beginning of the data packet. In navigating from layer to layer, the offsets of the desired fields must be calculated by the programmer based on the values found in the preceding fields.
Keeping track of the absolute location of fields in the packet is a tedious and error-prone process. At each stage of the decoding process, the program must look at the contents of a specified field, make a determination based on those contents, and then jump to another location based on that determination. The programmer must keep track of the current offset, write code to determine the next field to examine based on the current location and fields, and then move to that new absolute location. This is both tedious and error prone. What is needed is a system that automatically keeps track of the absolute locations and allows the computations to be carried out in a time consistent with decoding packets at the bandwidth of the communication link being monitored.